1. Field of the Invention
The present invention relates generally to the field of computer networks, more particularly to the flow of audio/video/media data through packet networks, and still more particularly to congestion detection and flow control over packet networks.
2. Description of the Related Art
Media data, such as audio or video data, has traditionally been broadcast over dedicated bandwidth RF (radio frequency) channels to ensure quality delivery to the receiver. With the explosion of the Internet and the accompanying deployment of broadband packet networks, the opportunity has arisen to include entertainment or media services along with other data services on the broadband networks. However, delivering streaming media over broadband packet networks at a marketable quality with current technology is difficult.
Existing best-effort packet networks were not designed for high-bandwidth real-time data, such as streaming video. These networks were designed to accommodate the economic average of data traffic, so they often confront congestion in various nodes of the network when peaks in data traffic occur. Such congestion results in the loss or corruption of packets and thus interferes with the quality level of real-time data. In particular, such congestion can cause interruptions or delays in streaming media, resulting in a quality of service that is inferior to broadcast standards and thus not marketable to a broad customer base.
Much of the general Internet operates as a packet network with the TCP/IP stack of protocols for packet transmission. TCP (the “transmission control protocol”) is responsible for breaking data into manageable pieces, reassembling and ordering the pieces at the other end, and retransmitting any pieces that are lost. IP (the “Internet protocol”) determines a route for the data pieces between the transmitter and the receiver. Application-level data, such as streaming media data, is broken into pieces and each piece is given a transfer header by TCP. An IP header is then affixed to each piece, followed in some cases by a data link header providing information relevant to the actual data link over which the data will be transferred. At the receiving end, these headers are removed in inverse order until the original data is recovered.
An alternative to TCP called UDP (User Datagram Protocol) may be used at the transport layer. Unlike TCP, UDP does not guarantee delivery, but UDP does deliver packets at a specified rate. It is thus often used for real-time application data. UDP is responsible for packetization, multiplexing, and performing checksum operations to verify the correct packet size. A second protocol, RTP (Real-time Transport Protocol), may be used in concert with UDP to handle data identification, sequence numbering, timestamping, and delivery monitoring.
FIG. 1 illustrates the organization of packets in the TCP/IP configuration. A packet of application data 100 first has a TCP header 102 attached. In the case of data for a real-time application, the TCP header 102 may be replaced with UDP/RTP header information as discussed above. Then a network layer or IP header 104 is attached, and finally a link layer header 106 is appended. The resulting packet is transmitted 108. As the packet is received 110, the headers 106, 104, and 102 are removed in inverse order so that the original application data packet 100 is available to the receiver.
Regional broadband networks, such as networks providing digital subscriber line (DSL) service into residences over existing telecommunications copper wire infrastructure, are growing in popularity. Such networks provide opportunities to introduce higher quality streaming media because they provide greater ability for network engineering and flow control than for instance the general Internet. These networks typically communicate through the use of the asynchronous transfer mode (ATM) protocol with IP over ATM over SONET (Synchronous Optical Network) for the backbone link and with IP over ATM over DSL for the last-mile link. ATM provides potential quality of service control unlike the TCP/IP protocol family used for the general Internet, but due to the increase in costs associated with commissioning such service, existing telecommunications access networks using ATM are not currently enabled for QoS (quality of service). Packet networks with QoS can reserve the bandwidth necessary for quality media streaming, but the significant expense associated with implementing this specification has thwarted its widespread introduction.
A variety of DSL specifications exist for providing data service over existing copper-wire telephone lines. Asymmetric DSL, or ADSL, is the most popular specification for residential customers, and it is reaching increasing numbers of households. ADSL is capable of providing downstream bandwidth in the 6 Mbps range over shorter distances, but more typically it can provide on the order of 1.5 Mbps of downstream bandwidth and 384 kbps of upstream bandwidth to a broad customer base. The potential for video content delivery over the general Internet, and specifically over DSL networks, is great, but its realization has been constrained not only by network congestion issues but also by the excessive bandwidth required for most quality video data. However, recent video compression advances by the assignee of this invention and potential future research allow broadcast quality video to be provided at compression ratios that are consistent with the typical 1.5 Mbps bandwidth constraint of ADSL.
As improving compression ratios make streaming video over ADSL or other constrained bandwidth networks feasible, several problems with implementation arise. In the presence of network congestion and a constrained last-mile link with limited headroom for error recovery, means must be found for avoiding error due to congestion-induced packet loss so that a service provider can maintain delivery of a high quality media stream to the client subscriber. Furthermore, as streaming media, especially video, proliferates and consumes significant bandwidth network-wide, flow control techniques for managing network-wide congestion increase in importance.
Existing flow control strategies for streaming media are minimal. Such strategies typically rely on server-side detection of congestion. Servers can monitor NACK (negative acknowledgement) signals that indicate when a client has not received a complete packet, and they can also monitor RTT (return trip time) to find how long packet transmission has taken. In the case of streaming over TCP/IP networks, TCP can guarantee loss-less delivery of packets but not timely delivery. Servers can initiate flow control measures such as stream switching when they detect network congestion. Such measures typically result in pausing of the stream and rebuffering with relative frequency. This interruption of service is unacceptable for a streaming media provider who wishes to market competitive high quality entertainment services to customers.